home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 20 / Cream of the Crop 20 (Terry Blount) (1996).iso / os2 / lxlt113.zip / LXLITE.ENG < prev    next >
Text File  |  1996-06-05  |  27KB  |  516 lines
  1.           ──────────────────────────────────────────────
  2.            LX lite - an compressor for OS/2 executables
  3.           ──────────────────────────────────────────────
  4.  
  5.                  Dedication: To my little daughter Alice,
  6.                          born 12 Feb, 1996 at 03:45.
  7.  
  8.   1. Distribution
  9.   ───────────────
  10.    This program is freeware. This mean that you can distribute it in any way,
  11.  except  for  commercial use. Commercial use is allowed ONLY with my personal
  12.  permission.  To  contact me see the the last section in this file. This also
  13.  means    that  you  have  NO  guaranties that it will perform exactly what YOU
  14.  need. I cannot carry any responsability for any damages, lost of profit etc.
  15.  caused  by  use  or  inability to use this program.
  16.    However,  you CAN use it to enhance any, even commercial, product. This is
  17.  not  for  YOUR benefit but rather for benefit of poor users who are BORED of
  18.  the big size of executables.
  19.    The    program is written exclusively in Virtual Pascal, beta 3, with use of
  20.  its  built-in    32-bit    assembler.  This is an excellent language which takes
  21.  full  advantages  of  OS/2`s possibilities, is BorlandPascal compatible, and
  22.  have  a  powerful  built-in optimizer. If you want the lxLite`s source code,
  23.  please  mail  me,  but  you have to tell me WHY do you need it, to avoid the
  24.  people which likes to re-sell other`s programs under their name.
  25.  
  26.   2. Introduction
  27.   ───────────────
  28.    I  think  all  of  us  are  really  bored  of  the  big  size  and reduced
  29.  functionality    of  all  those    modern    executables written to run under OS/2
  30.  (windos  too).  I  don`t  understand  why  they  are  so  big,  because most
  31.  compilers,  even  IBM    CSet  generate a modest size code. For a widely known
  32.  example  let`s  take  MultiMaint.  What  a complex task it performs that its
  33.  executable  occupies  more  that  700K?  I  don`t  understand. Moreover, WHY
  34.  duplicate  (and  triplicate)  almost  the same executable as it does (I mean
  35.  MultiSafe  and  IniMaint  which  comes along with MultiMaint). It performs a
  36.  nice  work,  but it is TOO big for the task it acomplishes. OS/2 kernel have
  37.  the  same  size.  I  cannot  afford such a large pile of shit on my HD, so I
  38.  killed MultiMaint & C°. :`-(. Too bad for its author.
  39.    Here is a workaround for this. You can just pack the executable so it will
  40.  be  twice  smaller  and  still perform the same task. Alas, it will grab the
  41.  same amount of memory as original executable does - this is the fault of the
  42.  program`s author.
  43.    As  far  as    I know there is only one program which does the same - REPACK
  44.  from  IBM  (EWS?).  But  compared  to lxLite it gives larger files using the
  45.  same algorithm. For example, COURIER.FON from OS/2 v8.192 it compresses into
  46.  44K  and  lxLite  into  34K.  Feel  the  difference.  BTW,  LINK386+Resource
  47.  Compiler  compiles  COURIER.FON  also into 44K-size file. This make me think
  48.  that they use the same common library.
  49.    I  packed  ALL  my executables (incuding but not limiting to ?:\os2\*.exe,
  50.  ?:\os2\dll\*.*  and  ?:\os2\dll\ibmnull;laserjet)  and  my  system  is stiil
  51.  working  fine    :-)  One  of lxLite users (Pavel Roskin) observed that lxLite
  52.  packs    even  os2krnl :-) This is a very nice feature to create a SINGLE OS/2
  53.  boot diskette.
  54.  
  55.   3. Features
  56.   ───────────
  57.    lxLite  compresses  the files in the same way as LINK386 does. There is NO
  58.  way  of  implementing a executable packing method other than those two which
  59.  Warp  uses  (or  the only for 2.x). So, here is a brief description of those
  60.  two algorithmhs:
  61.  
  62.    1.  Run-length packing. This is generally the same method that Microsoft C
  63.  for  DOS uses. It gives VERY bad results because the structure of executable
  64.  files    aren`t    suited    for that kind of packing. For example, PCX files uses
  65.  approximatively the same packing method.
  66.  
  67.    2.  Kinda Lempel-Ziv algorithm. Lempel-Ziv is the same method which almost
  68.  all  DOS  executables    packers  use  - LZEXE, PKLITE, PGMPAK etc. The method
  69.  standartized  for  OS/2  executable  files is not the most effective (IMHO).
  70.  Other    thing  is  that OS/2 executable have a different loading algorithm in
  71.  contrast to DOS executables - parts of OS/2 executables are loaded only when
  72.  they  are  needed.  So,  Lempel-Ziv  dictionary  cannot cross the bound of a
  73.  single page (4096 bytes). Because of this, it gives not such good results as
  74.  it can.
  75.  
  76.    lxLite  can    use any of these two methods either for packing or unpacking.
  77.  Generally  the second gives best compression rates, but may be (?) there are
  78.  some  files  on which first will work better. Because of this the default is
  79.  to  try  to pack page using both methods and then choose the smaller result.
  80.  lxLite can be used as well for unpacking the files that previously have been
  81.  packed - either by lxLite, LINK386 or REPACK from IBM.
  82.  
  83.    What  kind  of  files  you  can  compress?  The  LX    format is used almost
  84.  everywhere in OS/2: almost everything is in LX format. So, you don`t have to
  85.  limit    only  to  .EXE files: you can pack .DLL, .PDR, .QPR, .DRV, .FON, .SYS
  86.  (Virtual  Device Drivers (VDDs) in \OS2\MDOS) as well. You can run lxLite on
  87.  virtually  any  file:    if it is not in Linear Executable (LX) format it will
  88.  refuse to process it.
  89.  
  90.    You can also consider compressing your entire \OS2\*\ directory structure,
  91.  it  will  give you a lot of extra space and absolutely no overhead! The time
  92.  spent    for  decompressing  executables is recovered by the time which system
  93.  does  not  spend  for    reading  the  executable  from    HD  because it`s much
  94.  smaller!  So, reboot from stand-alone OS/2 diskettes (you can boot from OS/2
  95.  installation  diskettes  (first  two)    then  press F3), then change to drive
  96.  where your OS/2 is and type
  97.   \[path]\lxLite os2\*.exe os2\dll\*.* os2\dll\ibmnull\*.drv
  98.    and    so  on.  Also  you  can compress now the executables which are run at
  99.  system   startup,  because  when  they  are  run  you    cannot    modify    their
  100.  executables and DLL`s.
  101.  
  102.    lxLite  version 1.00 and above can replace executable modules even if they
  103.  are  currently  in use. In this case it will warn you that module is already
  104.  in  use by another process, and will propose you either to replace it by its
  105.  packed  version  or  either  to  skip    this module. Choose at your wish, but
  106.  keep  in  mind  that  the  modules you have replaced are kept now (their old
  107.  versions)  in    memory,  so they eat up your swapfile space. Better reboot as
  108.  soon as you have this opportunity.
  109.  
  110.    Versions  above  1.00 are supplied in two different executables: one named
  111.  lxLite.exe  is  the  usual  version  for OS/2 v2.99, Warp and aboves. Other,
  112.  named    lxLite2x.exe  is meant for use in old versions of OS/2 (i.e. 2.x, NOT
  113.  1.x because 1.x doesn`t have the LX format). Delete it if you`re a OS/2 Warp
  114.  user.
  115.  
  116.    Version 1.1.0 and above detects executables which contains some data after
  117.  the  LX  structure  itself  (i.e.  what`s  called  in DOS overlay data). For
  118.  example  Watcom`s  binded executables (such as WCC.EXE versions >= 10.0) and
  119.  Watcom  Visual  Rexx  executables  have  such structure. In this case lxLite
  120.  shows    an warning message and asks for confirmation whenever you really want
  121.  to  pack  such  executable.  It  is STRONGLY recommended that you backup the
  122.  executable  in  question  before trying to do it because it is VERY possible
  123.  that  it will become non-functional if something gets changed in it (because
  124.  lxLite  does  not change any of possible pointers in data binded to LX as in
  125.  VREXX executables).
  126.  
  127.  
  128.   4. Options
  129.   ──────────
  130.    There are alot of options in lxLite. I simply like options :-) So, you can
  131.  configure almost anything in lxLite. Moreover, to protect the user from need
  132.  of writing the same options lxLite support multiple configurations which are
  133.  kept  in  a  single  file.  lxLite  comes  with  some example configurations
  134.  (`factory defaults`) which are listed below:
  135.  ────────────────────────────────────────────────────────────────────────────
  136.   default: (loaded by default)
  137.    It is a `work` configuration. All parameters are set to maximize
  138.    compres